Software application installation is an area of increasing importance. Unfortunately, existing installation technologies fail to address all of a computer user's needs. Most installation technologies are simply brute-force mechanisms for copying program files from one location to another. Only one known installer program, Microsoft Windows Installer, developed by Microsoft Corporation, Redmond, Wash., even comes close. For a description of Microsoft Windows Installer, see Kelly, Mike, “Gain Control of Application Setup and Maintenance with the New Windows Installer,” Microsoft Systems Journal, pp. 1527, Sep. 1998.
The one installer program that comes closes to addressing all of a computer user's needs manages the installation of an application so that information related to each of the application's resources is stored in a “configuration database.” The configuration database may be registry keys within a system registry, or it may be a stand-alone database. The stored information includes, but is not limited to, the installed state of the application, i.e., what features of the application are or are not installed, whether the application should be run locally or run from a source, paths to the program files of the application, whether features are “advertised” (i.e., available but not installed), etc. The stored information is stored at install time and is used by the installer program to ensure that an application always has available the resources that it expects or that the user requests. For instance, one function of the installer program is to verify the existence of a resource needed by the application. When the application requests a path to a program file, the installer program verifies the existence of that program file at the expected location stored in the configuration database. If, for some unexpected reason, the program file does not exist at the expected location, the installer program installs the program file prior to returning its path to the application. The installer program continually updates the configuration database if any changes are made to the installed state of the application.
Once installed, there may be a need to change an application. Generally speaking, changes to an application may be minor, in which case a patch is desirable, or changes may be more significant, in which case an upgrade is desirable. For example, patching may be performed if an application is in need of a service release or update to remedy a programming bug or other infirmity, whereas an upgrade will be performed for a new release. The present invention is directed to upgrades, as opposed to patches. There are several problems with traditional methods of upgrading software applications.
First, traditional methods of upgrading software applications modify the resources of the application, but do not modify the configuration database maintained by the installer program to reflect those modifications. For example, an upgrade will often add a new program file to the application. However, the upgrade does not modify the configuration database to make the installer program aware of the existence of the new program file. In addition, the installer program is unable to update its configuration database to reflect the existence of the new file because the upgrade and new file were not installed by the installer program. The result is that the installer program is unaware that the new program file was added, so any additional functionality provided by the installer program is unavailable for that new program file. For example, the installer program is unable to verify the existence of the new program file if requested by the application.
Another problem with traditional methods of upgrading software applications is that they may not be able to properly upgrade an uninstalled or partially-installed application. At installation, the user may choose not to install all of the features of an application, but rather delay the installation of certain features until they are actually used. The installer program may provide an application with the ability to offer the feature as available although the feature is not installed (“advertising” the feature). When the user or application attempts to access that feature for the first time, the installer program automatically installs the advertised feature. This reduces the amount of storage space consumed by features of an application that are not initially used.
Yet another problem with traditional upgrades is that there is not a standard. This forces authors to create custom upgrade logic. This in itself is a significant problem, however, the problem is compounded in that this custom logic trickles down to the user. This means that upgrades of different products may have different installation procedures from the perspective of a user.
Accordingly, there exists a need in the art for an improved method of upgrading a software program that provides standardization from the perspective of both the author of the upgrade and the user installing the upgrade. In addition, a need exists for a method of upgrading a software program that can determine if any older versions of the software program are installed and act accordingly. Furthermore, the actions taken, i.e., current install state of the software program, should be stored.